A refactoring is a process for improving the design of software by applying several behavior-preserving transformations to a software system. M. Fowler, K. Beck, J. Brant, W. Opdyke and D. Roberts “Refactoring: Improving the Design of Existing Code”, 1st edition, Addison Wesley, 1999, gives an introduction to the subject. A refactoring engine is a software development tool usually offered as a service by an integrated development environment (IDE) to provide automatic code transformations, such as reference-adjusting renaming of software elements or reorganizing hierarchies of software artifacts. Refactoring engines automate the refactoring process and help developers to safely change information. Current refactoring engines are designed to work on a local set of artifacts conventionally called a workspace. The scope of refactoring operations therefore is naturally bounded by such a workspace. Artifacts not present in the workspace at the time of initiating the refactoring cannot be considered and hence are not updated by the refactoring engine.
Most of the time software development is performed as a collaborative process. Therein, software developers only work on a subset of an entire software project. Consequently, such a developer typically has only a subset of all the artifacts of the entire project loaded in his workspace. The propagation of changes to a software artifact is then done by a Version Control System (VCS), which acts as a centralized repository that stores all artifacts belonging to a software project.
Current refactoring engines require that all artifacts to be refactored are present in the workspace from which the refactoring operation has been initiated. Other developers having artifacts with references to the refactored artifact in their workspace may have to perform manual adjustments when accepting incoming changes from the VCS system, since their content has not been updated by the refactoring engine. Due to the definition of the scope of a refactoring operation, the delivered change information does not comprise information on how to resolve conflicts in additional artifacts in workspaces other than the original workspace.
In T. Ekman and U. Asklund, “Refactoring-aware versioning in Eclipse”, http://www.lucas.lth.se/cm/cmeclipse.shtml, describes previous work that has been done to enrich a VCS with refactoring information. However, this information is only leveraged during merge and compare operations and not to solve the consistency problem caused by the definition of the scope of refactoring operations performed by refactoring engines during update operations.
In J. Henkel and A. Diwan: “CatchUp! Capturing and Replaying refactorings to Support API Evolution. In ICSE”, St. Louis, USA, 2005 the authors are describing a refactoring engine that is able to capture refactorings performed on a workspace, and then later replay the refactorings on a different workspace. This refactoring engine however is a standalone system which is not integrated in a VCS and does not support collaboration by software repositories.
Dig et al. present in D. Dig, T. N. Nguyen, and R. Johnson: “Refactoring-aware Software Configuration Management”, Report No. UIUCDCS-R-2006-2710, April 2006 a refactoring-aware software configuration management system where change information is not stored as files, but as logical operations on source code. In conjunction with a refactoring engine which has been extended to record refactorings, this system stores refactorings as semantic operations in order to maintain a consistent history of a source code element. The semantic operations are then replayed on the workspace during update operations. This software configuration management system is a standalone solution which does not work with an existing resource-based VCS.
The Borland JBuilder 2005, described in Borland JBuilder 2005 Whitepaper, http://www.borland.com/resources/en/pdf/white_papers/jb2 005_whats_new.pdf, has support to record and replay refactorings. Refactoring information can be associated with a project archive from a project which is dependent on the project which the refactoring has been initiated from. This feature is called distributed refactoring, but does not leverage refactoring information during synchronization with a VCS.
In “CatchUp! Capturing and Replaying Refactorings to Support API Evolution” by Johannes Henkel and Amer Diwan, International Conference on Software Engineering, Proceedings of the 27th international conference on Software engineering St. Louis, Mo., USA, SESSION: Software evolution, Pages: 274-283, 2005, the creation of a meta data file containing refactoring information is described. Library developers who have to evolve a library to accommodate changing requirements often face a dilemma: Either they implement a clean, efficient solution but risk breaking client code, or they maintain compatibility with client code, but pay with increased design complexity and thus higher maintenance costs over time. A lightweight approach is discussed for evolving application programming interfaces (APIs), which does not depend on version control or configuration management systems. Instead, API refactoring actions are captured as a developer evolves an API. Users of the API can then replay the refactorings to bring their client software components up to date.
In the web article http://www.eclipse.org/articles/article.php?file=Article-Unleashing-the-Power-of-Refactoring/index.html, the author Tobias Widmer specifies how refactoring descriptors can be used to store refactorings for monitoring or later re-execution.
The challenge is the ability to extend an existing version control system to allow refactoring during an update operation.